From: [email-masked]
Date: Thu, 16 Feb 95 09:40:56 EST

This note is being placed on this mailing list because it pertains to
corrections to the APPN architecture regarding XID processing.  (What is
acceptable and not acceptable).  Check it out and feel free to chime in with
your two cents worth.

Tim

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Jim,

Thanks for the clarification!  I agree wholeheartedly with the principle
of performing no more error checking than is absolutely necessary.
When I started looking at XID error checking, I was shocked by the
list of 60+ sense codes in the APPN Reference.  I am glad that some
of them are not recommended anymore.

I just came across one more that I have to ask about.

10160018   Adjacent node is APPN but not support adaptive BIND
        pacing as a sender and receiver.

Making this check would seem to be a way to guarantee a migration
problem, since there are existing APPN products in the field that
don't support BIND pacing (Wall Data's RUMBA, for example).
We have recently added bind pacing, but we are certainly not
interested in rejecting XIDs from previous releases of our own
product.  No other APPN product that we have ever connected to
sends this sense code.  Should this one be ignored, too?

From: hefel
To: mallen
Subject: CS questions
Date: Wednesday, February 15, 1995 6:07PM

Mike,

Here you go.....

Date: 15 February 95, 10:22:24 EST
From: JIM  AMUNDSON             543/4644             AMUNDSON at RALVM6
To:   HEFEL

Tim,

  I'll add comments following the question as '>>>>'

Note #1
 -------
  But first some general comments.  Originally the architecture
listed how thing should go and provided a test and error code for
a lot of thing.  A product however is not interested in policing
the network but bringing up a link.  Thus a product may actually
want to accept minor errors if they don't hinder the valid operation
of the link.  If the question you ask falls in this category I will
answer with 'IGNORE' if I thing you could or should.

Note #2
 -------
  In the real world with delays, race conditions, and DLC time-outs
and retransmissions; XID's can and will arrive in sequences other
than expected.  FSM_XID3 was written to deal with the real world
and accept everything it can and still get a valid link up.
If the question you ask falls in this category I will
answer with 'ACCEPT' since I think you should ignore the problem.

Jim A
 ----------------------------------------------------------------------------
 --
Date: 14 February 1995, 17:41:21 EST
From: APPN1    at RALVM6
To:   AMUNDSON
Subject: Errors Detected in XID Processing

Re: Note from SMTP2 at IINUS1

More Q's from Walldata....what say ye, Jim?
 ------------------------------- Referenced Note ---------------------------
Received: from relay.interserv.com by vnet.IBM.COM (IBM VM SMTP V2R2) with
TCP;
   Thu, 09 Feb 95 12:12:10 EST
Received: from msmail.walldata.com ([198.252.72.131]) by relay.interserv.com
with SMTP id AA25970
  (5.67b/IDA-1.5 for [email-masked]); Thu, 9 Feb 1995 09:09:51 -0800
From: "Allen, Michael" <[email-masked]>
To: appn <[email-masked]>
Subject: Errors Detected in XID Processing
Date: Thu, 09 Feb 95 09:07:00 PST
Return-Receipt-To: <[email-masked]>
Encoding: 47 TEXT

Tim,

I have some more CS questions.

In the APPN Reference on page 9-52, there is a table "Errors Detected in XID
Processing".  The *implication* of this table is that all of these sense
values represent required validity checks.  However, in going through the
structured prose, FSMs, and description of XID Format 3 I-field on page
9-221,
there are inconsistencies.  In those cases where one of the sense codes
on page 9-52 is not referred to anywhere else, I am assumed that the implied
test is required.
>>>> NO.  Some old products may set these code.  See note #1 above for
>>>>      how you can function.

However, the tests implied by the following codes in the
table seem to be in conflict with statements in the structured prose or
FSMs,
so should I assume that the validity checks are *prohibited*?

   0809003A - Null XID received when activation XID3 expected
>>>> ACCEPT

   0809003C - Preneg XID3 received when NOESI or neg proceeding expected
>>>> ACCEPT

   08090041 - Negotiation proceeding received when prenegotiation expected
>>>> ACCEPT

   08090047 - XID received before modesetting command completed
>>>> ACCEPT

   10160014 - NRM station indicated neg role but previously was non-neg
>>>> IGNORE if the previously ESI=non-neg was on a prior link activation.
>>>> ERROR  if the previously ESI=non-neg was during this link activation.
>>>> ACCEPT if you want.  If you want to allow this, who is to care?

        In FSM_XID3 on page 9-182, "Note 2" at the bottom of the page
        says that XID processing should *not* be terminated with a CV22
        error if XIDs are received out of sequence.  The out-of-sequence
        XID is responded to with a copy of the last XID sent by this node.
>>>> This is the principle you should follow!

   08090048 - NRM secondary sent unsolicited XID

        In FSM_XID3 on page 9-182, "Note 1" at the bottom of the page
        says that, while it is an error if an NRM secondary station
        sends an unsolicited XID after the mode-setting sequence has begun,
        the stray XID is not a problem for CS and should simply be ignored.
>>>> This is the principle you should follow!

Can you please clarify this point for me?  If this interpretation is
correct, will the table on page 9-52 be corrected in the next issue of
the book?
>>>> Hopefully.

And could a clarification be posted on the architecture reference
mailing list?
>>>> Tim, your call.

Thanks,
Mike

=========================================================================
Date: 14 February 1995, 17:42:24 EST
From: APPN1    at RALVM6
To:   AMUNDSON
Subject: Sense data for inconsistent netid.cpname on activation XID3

Re: Note from SMTP2 at IINUS1

'Nother CS question......what say ye, CS guru?

 ------------------------------- Referenced Note ---------------------------
Received: from relay.interserv.com by vnet.IBM.COM (IBM VM SMTP V2R2) with
TCP;
   Tue, 07 Feb 95 20:23:41 EST
Received: from msmail.walldata.com ([198.252.72.131]) by relay.interserv.com
with SMTP id AA27178
  (5.67b/IDA-1.5 for [email-masked]); Tue, 7 Feb 1995 17:21:25 -0800
From: "Allen, Michael" <[email-masked]>
To: "'Hefel, Tim'" <[email-masked]>
Subject: Sense data for inconsistent netid.cpname on activation XID3
Date: Tue, 07 Feb 95 17:20:00 PST
Encoding: 16 TEXT

Tim,

I'm looking at XID3_ACTIVATION_CHECKS on page 9-165 of the
APPN book.  The pseudo code says to verify that the adjacent node
has been consistent in the name it has sent in CV0E on XID3s during
an activation exchange.  However, there is no indication about what
sense value to use for that error.  The table of applicable sense codes
on page 9-237 does not include one for this error, nor is there one in
the master list of sense codes on 9-52.

Does this lack of a sense code indicate that this check is unnecessary,
or is there another sense value that should be used?
>>>> No, this is a valid check and the sense code set is
>>>>     0806002C

Thanks,
Mike